X Windows applications were developed for UNIX software platforms decades ago but continue to be in wide use today for many important applications including industrial graphics design. Companies have a lot invested in X applications and wish to continue to use and support them despite changes in network topography, workstation hardware and server architectures. Software companies such as Attachmate provide so-called X servers such as Reflection X® that continue to support this important X server legacy functionality.
In more detail, the X Window System (commonly X11 or X) is a networking and display protocol which provides windowing on bitmap displays. X originated at MIT in 1984. The current protocol version, X11, appeared in September 1987. The X.Org Foundation leads the X project, with the current reference implementation, version 11 release 7.2 (Feb. 15, 2007), available as free software under the MIT License and similar permissive licenses, incorporated herein by reference. X provides the standard toolkit and protocol to build graphical user interfaces (GUIs) on Unix-like operating systems and OpenVMS, and is supported by almost ALL other modern operating systems. X also provides the basic framework, or primitives, for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard. X does not mandate the user interface—instead, individual client programs handle this. X features network transparency: the machine where an application program (the client application) runs can differ from the user's local machine (the display server). See also Wikipedia article on “X Window System” on the Internet.
The traditional X server is a monolithic application, written in C and developed over a period of two decades. It implements a network-based graphical windowing environment for applications known as “X clients.” An X server accepts incoming connections from X clients, processes X protocol produced by these clients, and displays output in accordance with this protocol. The display may consist of one or more screens, but all screens are generally connected to one machine. There is only one display per instance of the X server. This X server instance is referred to as an “X session.” In modern times, such display functionality is typically provided on a user's LINUX, WINDOWS, UNIX or other platform through an emulation process that provides suitable mapping/translation between X protocol and physical personal computer displays and input devices.
The traditional X server's design imposes several limitations. For example, any hardware or network failure in the X server generally causes clients to disconnect and crash. A second limitation is that session sharing is not possible without additional software, commonly referred to as a server proxy or a “middle tier” component. Such a “middle tier” component can be used to intercept X client protocol and duplicate to all X servers or displays in the shared session.
Using one exemplary prior art approach, a middle-tier “headless” X display is maintained on a server machine at all times, and a viewer application is developed to display the contents of that X display on a remote machine. Oftentimes, different viewers have needed to be developed for different remote machines.
Another past approach to session sharing has been to capture all X protocol for the entire session; then create a new X server, and replay the captured protocol into the new X server, thereby bringing the new X server to a state identical to that of an existing X server. However, this replaying process takes time. As more and more client protocol is generated and stored, the burden of replaying that protocol becomes larger and larger.
While much work has been done in the past, further improvements are possible and desirable.
The exemplary illustrative non-limiting implementation permits the display to be dynamically rerouted to a different graphics terminal, or to several graphics terminals, without disrupting X clients. In more detail, the exemplary illustrative non-limiting implementation breaks the previously-monolithic X server into two parts:                a static part which acts as an endpoint for client connections and which routes X protocol to one or more X server displays (the “protocol router”); and        a dynamic part which maintains the state and contents of the display (the “X display”).An X display may maintain its state and display contents entirely in memory without any need for physical display or input devices, in which case it is termed a “headless X display” and provides a virtual X server display that appears to the host as if it were a user-interactive display when in fact it comprises an entirely automated computer process that does not require user input or interaction in order to keep a session active or “alive.” The architecture allows for any number of X displays to be attached to the protocol router.        
The exemplary illustrative non-limiting implementation creates a new X display to be attached by serializing or “cloning” an existing X display to create the new one. This serialization technique involves taking a snapshot of the entire memory footprint of the X display, sending that snapshot to another machine and recreating a completely new X display which has state and contents identical to the original X display. Such platform-independent migration has many advantages in terms of fault tolerance, mobility, etc.
Exemplary illustrative non-limiting features and advantages of the exemplary illustrative non-limiting implementations disclosed herein include:                Does not require a middle tier or permanent headless X server.        Any X server can be used as a source for cloning a new X server.        Avoids doubling the computing burden necessary with a middle tier (where graphics are drawn to the headless X server, as well as on all viewers.)        Alleviates the need for development of a separate viewer application and concomitant protocol.        Instantaneous, as compared to the approach of replaying X protocol.        Permits a user to insure their session against local machine or connection failure at any time, by creating a headless X display from the user's X display and parking it on a “safe” machine (inside the company's firewall, for example).        All the advantages of a middle tier solution without requiring the middle tier; and none of the disadvantages of a protocol-replaying solution because the current state of an X server can be captured and reproduced at will.        Imposes no additional burden when running in the canonical “one protocol router, one X display” mode. Both pieces may run inside the same process, and effectively reproduce the original configuration of a single X server.        “Headless” X display created only when a session is suspended.        X server written in a language such as Java that supports object serialization (i.e., an object oriented language) provides platform-independence.        
There are at least three contexts in which the exemplary illustrative non-limiting implementation would be useful:
1) To suspend a session (e.g. at work) and resume it elsewhere (e.g. at home)
2) To share a session with other users (e.g., a classroom lecture; or, a user who temporarily needs help from the help desk)
3) To provide a backup against failure of the network (e.g. while working remotely over a poor quality line) or failure of the user's local machine.